.github/workflows/prettier.yml (1)

40-44: Pin Prettier version or use project's version.

Installing Prettier globally without a version constraint may lead to inconsistent behavior across workflow runs when new Prettier versions are released. Consider either:

• Pinning to a specific version: pnpm add -g prettier@3.x.x
• Installing from the project's package.json: pnpm install && pnpm exec prettier --check .

🔎 Option 1: Pin to a specific version

-      - name: Install Prettier
-        run: pnpm add -g prettier
+      - name: Install Prettier
+        run: pnpm add -g prettier@3.4.2

🔎 Option 2: Use project's Prettier version (recommended)

+      - name: Install dependencies
+        run: pnpm install
+
       - name: Check formatting
-        run: prettier --check .
+        run: pnpm exec prettier --check .

Remove the "Install Prettier" step entirely in this approach.

.github/workflows/markdown-check.yml (1)

14-14: Consider parameterizing the rumdl version.

The hardcoded version (v0.0.185) will become outdated. Consider either:

• Using a workflow input to specify the version
• Pinning to a major version tag if available
• Documenting the version update process

.github/workflows/commit-check.yml (1)

24-25: Consider pinning commitlint version.

Similar to Prettier, installing commitlint without version constraints may lead to breaking changes when new versions are released. Consider pinning to specific versions:

-        run: pnpm add -g @commitlint/cli @commitlint/config-conventional
+        run: pnpm add -g @commitlint/cli@19.0.0 @commitlint/config-conventional@19.0.0

.github/workflows/pr-checks.yml (1)

38-51: Consider simplifying conditional logic for clarity.

The conditional expressions work correctly but are complex. The pattern (inputs.run-X != false || github.event_name != 'workflow_call') effectively means:

• For direct PR triggers: always run (since inputs are only defined for workflow_call)
• For workflow_call triggers: respect the input

While functional, this could be clearer:

🔎 Alternative: Explicit handling by event type

   prettier:
     needs: check-draft
-    if: needs.check-draft.outputs.should-run == 'true' && (inputs.run-prettier != false || github.event_name != 'workflow_call')
+    if: |
+      needs.check-draft.outputs.should-run == 'true' && 
+      (github.event_name == 'pull_request' || inputs.run-prettier != false)
     uses: ./.github/workflows/prettier.yml

This more explicitly shows that PR events always run while workflow_call respects inputs.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

.gitignore (1)

1-1: Consider adding common Node.js and pnpm artifacts.

While node_modules is correctly ignored, consider enhancing this file with common entries that align with the pnpm/Node.js tooling being introduced:

• pnpm-specific: pnpm-debug.log*, .pnpm-store/ (if using workspace)
• General logs: *.log (catch npm/yarn logs too)
• Environment files: .env, .env.local
• OS artifacts: .DS_Store, Thumbs.db
• IDE artifacts: .vscode/, .idea/ (optional, team preference)

This is optional and depends on your project's scope, but it aligns with standard Node.js/pnpm hygiene.

🔎 Example enhanced .gitignore

+# Dependencies
 node_modules
+
+# Logs
+*.log
+pnpm-debug.log*
+npm-debug.log*
+
+# Environment
+.env
+.env.local
+
+# OS
+.DS_Store
+Thumbs.db

.github/workflows/prettier.yml (1)

40-41: Consider pinning the Prettier version for consistency.

Installing Prettier without a version constraint may lead to inconsistent formatting checks over time as Prettier releases updates. Different workflow runs could use different Prettier versions, potentially causing unexpected failures.

🔎 Suggested approaches

Option 1: Pin to a specific version

-      - name: Install Prettier
-        run: pnpm add -g prettier
+      - name: Install Prettier
+        run: pnpm add -g prettier@3.4.2

Option 2: Install project dependencies if package.json exists (more flexible)

       - name: Install Prettier
-        run: pnpm add -g prettier
+        run: |
+          if [ -f "package.json" ] && grep -q '"prettier"' package.json; then
+            pnpm install --frozen-lockfile
+          else
+            pnpm add -g prettier@3.4.2
+          fi

Then update the check command to use the local version:

       - name: Check formatting
-        run: prettier --check .
+        run: npx prettier --check .

.github/workflows/pr-checks.yml (1)

38-57: LGTM! The conditional logic correctly handles both event types.

The workflow properly orchestrates the three check workflows, respecting both the draft PR status and selective check inputs. The conditional logic ensures checks run by default for direct PR events while honoring the input flags when called via workflow_call.

💡 Optional: Add clarifying comments

The conditional logic is correct but somewhat complex. Consider adding inline comments to explain the dual-mode behavior:

   prettier:
     needs: check-draft
+    # Run if not draft AND (always for direct PR events OR input not explicitly disabled for workflow_call)
     if:
       needs.check-draft.outputs.should-run == 'true' && (inputs.run-prettier !=
       false || github.event_name != 'workflow_call')
     uses: ./.github/workflows/prettier.yml

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

.github/workflows/pr-checks.yml (3)

45-47: Consider reordering the condition for better readability.

The condition works correctly but could be more idiomatic by checking the event type first:

-    if:
-      needs.check-draft.outputs.should-run == 'true' && (inputs.run-prettier !=
-      false || github.event_name != 'workflow_call')
+    if:
+      needs.check-draft.outputs.should-run == 'true' && (github.event_name !=
+      'workflow_call' || inputs.run-prettier != false)

This makes it clearer that checks always run for direct PR triggers and only respect the flag when called as a reusable workflow.

---

54-56: Consider reordering the condition for consistency.

Same readability improvement as the prettier job for consistency:

-    if:
-      needs.check-draft.outputs.should-run == 'true' && (inputs.run-markdown !=
-      false || github.event_name != 'workflow_call')
+    if:
+      needs.check-draft.outputs.should-run == 'true' && (github.event_name !=
+      'workflow_call' || inputs.run-markdown != false)

---

61-63: Consider reordering the condition for consistency.

Same readability improvement for consistency with other jobs:

-    if:
-      needs.check-draft.outputs.should-run == 'true' && (inputs.run-commits !=
-      false || github.event_name != 'workflow_call')
+    if:
+      needs.check-draft.outputs.should-run == 'true' && (github.event_name !=
+      'workflow_call' || inputs.run-commits != false)

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

package.json (1)

5-5: Consider removing the main field.

The main field typically points to the entry point of a Node.js package. Since this appears to be a GitHub Actions repository rather than a publishable npm package, and no index.js file is evident in the PR, this field is likely unnecessary.

🔎 Proposed fix

  "description": "",
- "main": "index.js",
  "scripts": {

.github/workflows/prettier.yml (1)

12-28: Consider making the config check more robust.

The current check on line 24 uses grep -q '"prettier"' "${{ inputs.package_json_file }}", which may produce false positives if "prettier" appears in other contexts (e.g., in a script name or dependency comment). Consider using jq for more precise JSON parsing.

🔎 Proposed improvement

       - name: Check for Prettier config
         run: |
           CONFIG_FILES=".prettierrc .prettierrc.json .prettierrc.js .prettierrc.yaml .prettierrc.yml .prettierrc.toml prettier.config.js prettier.config.mjs"
           HAS_CONFIG=false

           for file in $CONFIG_FILES; do
             if [ -f "$file" ]; then
               HAS_CONFIG=true
               break
             fi
           done

-          if [ "$HAS_CONFIG" = false ] && ! grep -q '"prettier"' "${{ inputs.package_json_file }}" 2>/dev/null; then
+          if [ "$HAS_CONFIG" = false ]; then
+            if [ ! -f "${{ inputs.package_json_file }}" ] || ! jq -e '.prettier // .devDependencies.prettier // .dependencies.prettier' "${{ inputs.package_json_file }}" > /dev/null 2>&1; then
               echo "::error file=.prettierrc::No Prettier configuration file found."
               echo "Please create a .prettierrc file or add prettier config to package.json"
               exit 1
+            fi
           fi

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

.github/workflows/commit-check.yml (1)

24-28: Consider refactoring config detection for maintainability.

The single-line conditional (line 26) checks multiple config formats but is difficult to read and maintain. Additionally, it's missing some valid commitlint config formats like .commitlintrc.cjs, .commitlintrc.mjs, and commitlint.config.js.

🔎 Suggested refactor for better readability

       - name: Create commitlint config if missing
         run: |
-          if [ ! -f .commitlintrc.json ] && [ ! -f .commitlintrc.js ] && [ ! -f .commitlintrc.yml ] && [ ! -f .commitlintrc.yaml ] && ! grep -q '"commitlint"' "package.json" 2>/dev/null; then
+          # Check for any existing commitlint configuration
+          if ! ls .commitlintrc* commitlint.config.* >/dev/null 2>&1 && \
+             ! grep -q '"commitlint"' package.json 2>/dev/null; then
+            echo "No commitlint config found, creating default configuration..."
             echo '{"extends": ["@commitlint/config-conventional"]}' > .commitlintrc.json
           fi

This approach uses file globbing to detect any commitlint config file and is more maintainable.

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro